In essence, a WINS server is a p-node server as defined in RFCs 1001 and 1002. However it is proprietary to Microsoft in implementation. WINS servers have NetBIOS name-to-IP address databases that are built automatically from a variety of sources:
Since the WINS servers are populated by so many forms of network activity, they require almost zero administration, and are extremely reliable at the same time. This makes them the best choice for NBT mappings. A single WINS server that all clients point to can be used to enable browsing across an entire world-wide network, since the reliance on broadcasting has all but been eliminated.
Also, clients that do not have WINS software and (and therefore rely on broadcasting) can take advantage of the WINS servers, since the latter will respond to a broadcast on behalf of a remote system. This means that all NBT nodes now can know about any other node that the WINS server knows about, increasing your network's overall reliability.
As an additional note, you can distribute WINS servers to each of your various network segments. This will provide your local Windows for Workgroups PCs with a browsable interface to your entire network.
To enable name resolution with WINS servers, add the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. If the [NBT] section does not exist, create it.
NameServer1=WINS_IP_address
where WINS_IP_address is the IP address of your WINS server. You can also add a secondary WINS server if you want by defining the "NameServer2=" entry.
If you do not want your WINS servers queried before broadcasts are issued, you can change the search order by adding the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. You MUST have a NameServerX entry defined before you set this flag. Otherwise, you will receive name resolution errors.
NodeTYPE=4
The LMHOSTS database is a raw text file whose format is functionally identical to the TCP/IP HOSTS file. It contains a numerical IP address, a tab character, and a NetBIOS name (and optionally, a comment). LMHOSTS is read by NBT at startup and designated entries are stored in the NBT name cache. This has the absolutely wonderful effect of eliminating all broadcasts destined for nodes or services that are listed in the LMHOSTS file, since the NBT name-to-address entry is already cached.
Do not confuse the LMHOSTS database with the HOSTS database. Although they are similar in use and structure, they serve two entirely separate purposes. The HOSTS file is a database of TCP/IP host names and their corresponding IP addresses, while the LMHOSTS file is strictly for NetBIOS name to IP address mapping. Typically, the LMHOSTS file only shows a few systems. This does not mean that there are only a few nodes on the network, but that there are only a few remote nodes that must be addressed directly. Simply put, the LMHOSTS file allows NBT to take advantage of both the broadcasting and point-to-point architectures without requiring that a dedicated nameserver be on your LAN. Realizing that the "LM" in "LMHOSTS" stands for "LAN Manager" may make the clarification easier.
To enable name resolution with an LMHOSTS file, add the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. If the [NBT] section does not exist, create it.
LMHostFile=C:\MULTINET\LMHOSTS.
You will need to use Notepad or some other text editor to actually create the LMHOSTS text file.
A sample entry in the LMHOSTS file might look like this:
198.93.23.13 TGVFTP # TGV's Public-Access FTP Server
This line simply tells NBT that any NetBIOS queries that are destined for the NetBIOS node TGVFTP are supposed to go to 198.93.23.13. By default, this name would be matched after a broadcast had been issued to the client's local IP broadcast address.
You may also need to define NetBIOS service name mappings. Just as a workstation has a NetBIOS name, so do services such as NetBIOS-based SNA gateways and other workgroup applications. An example of an application entry in the LMHOSTS file might look like the following:
127.1.1.1 SNAGATEWAY # IP address of service SNAGATEWAY
This would tell NBT that the service SNAGATEWAY can be located on the host 127.1.1.1. If you had an SNA terminal emulator that needed to connect to the gateway system using the NetBIOS service name of SNAGATEWAY, then NBT would build an IP packet destined for 127.1.1.1 with a NetBIOS datagram in it.
You need to be careful about the entries you put into your LMHOSTS file. If they are not the correct name or IP address, you will obviously not get the benefit you desired. Some of the most common problems come from not providing the exact NetBIOS host name as the destination system sees it. For example, you cannot simply define the hostname of TGVFTP as TGVSERVER. The server service will not understand the request. Other problems arise when you specify the wrong IP address of the destination system. If NBT has a name-to-address mapping available, it will use it. Providing the wrong address will cause very long delays as the timeouts will have to clear before control is returned to your system.
Since NetBIOS doesn't use port numbers like TCP/IP does, its flat and limited namespace must be capable of supporting a variety of names for each destination system. For example, if you are running an SNA gateway, a licensing server, and a client-server application all on the same system, each of these services must have a unique NetBIOS name that indicates the service itself. The service will not respond if the incoming name does not match the actual service name itself.
Some vendors have gotten fairly creative over the years in assigning these NetBIOS names to their services. Some of them are case-sensitive, while other have gotten into the habit of using hexadecimal characters. While technically this is not a problem in the broadcast-centric nature of NetBIOS LANS of old, it becomes a difficulty when you are working with services running on remote servers.
NetBIOS names can be up to 15 characters in length, with a 16th byte reserved for special end-of-name terminators. In order to identify these names, you must enclose the entry in quote marks, like this:
127.1.1.1 "ScrewySvcName" # Weird NetBIOS service name entry
If you have to use a hex character in the name, then you must preface the character with the tag "\0x", like this:
127.1.1.1 "GATEWAY \0x20" # NetBIOS service name with
# Hex character
The above example would put the hex "20" in the 16th byte of the NetBIOS name.
Whenever a client attempts to log onto a LAN Manager domain, broadcasting is used. Normally, a broadcast message follows the chain of events described above, but where domain controllers are involved, it is sometimes necessary to bypass normal channels. You can tell Windows for Workgroups that it is supposed to attempt domain logins with the hosts that are specified by using the #DOM flag.
In fact, you might want to add #DOM flags for all of the login servers in your domain. Then if the primary domain controller fails, the login request will get sent to the next server listed with a #DOM entry.
To signify that a system is a domain controller, put the #DOM:DOMAIN_NAME flag in the LMHOSTS file as follows, where DOMAIN_NAME is the name of the LAN Manager domain that you wish to login to:
127.1.1.1 MARKETING1 #DOM:MARKETING # Marketing PDC
Note that Windows for Workgroups PCs can NOT login to PathWorks domains at the time of this writing. Although PathWorks is based on LAN Manager, DEC has implemented proprietary mechanisms for logging into PathWorks-based domain controllers. This will not prevent you from connecting to resource on PathWorks servers; it only means that you cannot LOGIN to the domain if you only have PathWorks servers.
Because of TCP/IP's 32-bit numerical node addressing, it is a truly distributed network protocol capable of spanning huge distances and multiple network segments. Unfortunately, these numbers are awfully hard to remember. This is why DNS was invented; it provides a hierachial namespace that maps to IP addresses. Users can reference the host FTP.TGV.COM instead of having to remember that its IP address is 198.93.23.13.
While Microsoft has gone off and developed WINS as a mechanism for building databases that map IP addresses to NetBIOS names, DNS has been around for years, and provides a much more robust mechanism that all applications can use, instead of just NetBIOS apps.
However, the NetBIOS limitations of NBT still apply. The NetBIOS name you are querying for must match the name as registered by the system that owns it. Therefore, it is not possible for you to view the resources on the host FTP.TGV.COM by referencing it with that name. You must refer to it by it's NetBIOS name of TGVFTP.
This severly limits the usefulness of DNS as a NetBIOS name-to-IP address mapping tool. However, it is still very useful for viewing nodes that are in your same TCP/IP domain name. If you had a server called MARKETING1 that was also listed in the DNS under that same name, then you could do away with LMHOSTS and WINS altogether, and just use the existing DNS servers.
To enable name resolution with DNS servers, add the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. If the [NBT] section does not exist, create it.
EnableDNS=1
You will then need to create another section in SYSTEM.INI called [DNS], and under that add the following entry:
DNSServers=DNS_IP_address DNS_IP_address
where DNS_IP_address is the IP address of your DNS server. You can add up to two DNS servers in this field.
Perhaps you are on a small isolated LAN segment yet you often communicate with servers at your corporate headquarters. You would want to take advantage of WINS servers that were on the remote LAN, but you would not want ALL of your name queries to go to that host before broadcasts were attempted locally. Instead, you might want to broadcast first, and if that failed then go check the WINS server. This would give you quick connections to the local services and hosts, while guaranteeing name resolutions (via WINS) for remote systems.
To change the WINS and broadcasting search order, you need to define one of the following entries in the [NBT] section of SYSTEM.INI. You MUST have a NameServerX= entry already defined, or else you will get name resolution errors.
NodeTYPE=1 ; b-node, use broadcasts ONLY NodeTYPE=2 ; p-node, use WINS servers ONLY NodeTYPE=4 ; m-node, use broadcasts, then WINS NodeTYPE=8 ; h-node, use WINS, then broadcasts